From here on out, there are a number of processing and display subs. 
 xPost is the big one that ties most of them together.
 Others only interact for some single purpose.
 This session will begin by mentioning some of those purposes. 
 

 Sub ScrollChange (sender as QScrollbar)
 The sender parameter isn't necessary for our program yet. It may be useful later.
 It is the OnChange vector for all three scrollbar slide bars.
 The SelectColor panel displays the color selected with the RGB scrollbars.

 Sub xMode
 Activated by a mouse click on the MODE button.
 It simply toggles the mode between the AND and the XOR mode.
 The text on the button reflects which MODE the editor is in.
 The MODE selected influences much of the functionality of the display.

 Sub xPOST
 This code is where a lot of the program gets tied together.
 Three important nested subs are:
       Sub ColorMap
       Sub XorMap
       Sub AndMap
 This sub call them in turn, followed by turning the eHEX selected text highlights OFF
 RapidQ does a fantastic job of keeping vector houskeeping in order. Just avoid GOTOs.


 Sub ColorMap
     The section of data that contains the color codes is located on the hex display 
     beginning at character position 219 and is 191 characters long.
     use eHEX.text to capture these data in the c$ variable.
     each set of color data, in BGR format is 12 ascii bytes in length in eHEX

  FOR each of the 16 colors in this block of data, using variable C as an index...
      capture each byte's value the same way as in the xNEWz sub routine.
      sum them into a BGR color value and store them into the colortable(0 to 15) array.
      also use them to paint each pallette(0 to 15) with the appropriate color.
  Next C
      Additionally, each color is texted to ensure that the SelectColor that is used 
      to edit the image is indeed in the color map. If it is not, then the SelectColor 
      is set to the first color in the Color Tabel. Our Icons only permit using 16 colors
      by format. If the SelectColor is in the Color Tabel, then it is left as it is.
      The Activecolo.hint is the ascii hex palette color that was selected.
      The Palette.hint is the ascii hex character for its palette number.

      The color palette section is quite active in this program.
      The OnEvents for the color palettes do a lot of work. This will be covered later.



 Sub XORMAP
     This is also a very active area for our coding. The OnEvents will be covered later in
     detail. For now, extracting the image section of the bitmap will be covered. It is 
     responsible for coloring the pixels in the icon sized QCanvas and the magnified image 
     in the zoomed up QCanvas. One of the 16 colors is defined with four binary bits, so
     each byte in the XOR section makes one pixel color on the icon. 4 bits per pixel.

     First, capture the eHEX ascii data for this section. 416 characters beginning at 1536.
     Variables px and py are used to identify the pixel location in both QCanvases.
     The eHEX section is displayed in 32 15 byte (32 4 bit nibbles) for 32x32 pixel icons.
     Look closely and you can even see the inverted image in the ascii bytes displayed.

  FOR each of the 32 rows and 15 bytes (32  4 bit nibbles) per row.... (py and px)
      grab the 4 bit msb and the 4 bit lsb for each byte in the 16 rows, a byte at a time.
           ( as before, the 0 to F character in HX$ is the color table number)
      capture into msbcolor and lsbcolor variables the two pixel colors for that byte.
      PSET those two pixel colors into the QCanvas icon sized image.
      Repeat for the magnified image using the QCanvas.fillrect method.
      decrement three numbers from the byte count for two nibbles and a space in C$
      counting backwards is because the image in the bitmaps are inverted for some reason.
  NEXT px and py

      You will notice a lot of "selected", highlighted movement on the Image section of
      the eHEX ascii bytes when you are in the XOR mode and moving the cursor over the 
      QCanvas x8 image. These are the bytes in the eHEX ascii display that correspond 
      to the pixel you are cursing at with the mouse. This makes it easy to edit the image
      using the keyboard input to the eHEX display rather than clicking the mouse. In any
      case it makes the icon specs more visible for understanding the icon file structure.



 Sub xAND
     This is the section of code in the icon file that determines which of the icons are 
     to be transparent. It begins at character 1957 in the eHEX display, length 384.
     Each bit indicates either transparent or a solic color, eitht pixels for each byte.
     The entire text is captured into K$ with the eHEX.seltext function.

     using n for an index, K$ is copied to C$, less spaces. inx becomes the C$ pointer.
     Nested px and py transverse c$ data much the same as in the xAND sub-routine.

     Servicing each character (0 to F), with a FOR-NEXT loop
     IF the individual bit of the 4 bit nibble is a 1 then color that pixel with FormColor.
     do this for each pixel in the icon image and the rect in the magnified image.
     The n$ gymnastics converts the ascii hex to ascii binary, four bits with leading zeros.
     Each of the bits in turn, either paint the form color or the palette color.
     decriment the index pointer and continue through all the px and py positions.

     Here again, if the AND mode is set, the magnified image's cursor will highlight 
     the nibble in the eHEX display as the cursor is moved over the image. Explained later.

 
 sub xNEW
     This is a sub-routine that isn't one of the xPOST nest, but this is a good place to
     talk about it. On program start, we are invided to open a file for processing.
     We may not wish to examine or edit some existing file, but create a new icon instead.
     This module simply loads a canned icon into the eHEX display and copies it into 
     the z() array. Then using already existing sub routines, xposts it to the display 
     as if it had been sourced from the a storage device. This feature proved useful.
     It can easily be saved intact or edited as a new icon for our library of RQ icons.

     C$ is loaded with the data, sent to the z() array as data bytes with xNEWz, and
     sent to the display for examinagion and-or editing with xRESTORE. 
     


 

This session had covered all the sub-modules in detail. I like to write my programs in a
modular fashion because it is rather easy to make changes at a whim. This makes it nice 
for me; however, its not the best way to make programs to share with others.
RQDOC goes into detail on how to generate stand alone subs and functions that can be placed
in a library with necessary include files that share programs more conventionally.
But for now, its important to be able to create the programs we want. Perhaps groom for 
sharing later.

Moduler code is also a habit that us old timers picked up back in the old days when BASIC 
was the only way to go. Also when it cost as much for 64k of RAM as a second hand PC with 
WINDOWS costs now. Back then, bloatware was a no no.

You may wish to copy some of these modules into a library ( directory or folder ) with 
a unique file name and pass parameters back to the calling program. This permits writing 
another program that calls them as you wish. It will also simplify the use of variables.
As explained in RQDOC, variables used in subroutines need not be dimensioned globally in 
the new program we are creating. It only requires an open and closing paren with the 
variables named as parameters in the SUB's DECLARATION statement in the new program.

You will indoubtedly develop you own way of doing these things. Thats artists license.

 

We have petty well covered out program in regards to DATA aquision and display. It is
essentially a good tool for learning how an icon file is constructed. Its still rather 
static until the dynamics of Editing is considered. The interaction with the mouse, using 
the QObject's OnEvent modules make the program much more dynamic and interactive.

The ups, downs, changes and moves of our mouse will be discussed in the next sessions.
Remember, uSOFT and cats have two things in common. They both like windows and mouses.

Happy Hacking